Denial of service (DoS) attacks cause service disruptions when limited server resources are allocated to the attackers instead of to legitimate users. A distributed denial of service (DDoS) attack launches a coordinated DoS attack toward the victim from geographically diverse Internet nodes. The attacking machines are usually compromised zombie machines controlled by remote masters. The resources typically under attack include link bandwidth, server memory and CPU time. Distributed DoS attacks are more potent because of the aggregate effects of converging traffic, especially when the attackers have inside knowledge of the network topology. “TCP SYN flood,” “smurf IP ping,” and bandwidth attacks on root name servers are all examples of such attacks which have been previously deployed. (Each of these attacks will be familiar to those skilled in the art.) However, it has been reported that there have in fact been far more of such attacks than have been previously known.
There are numerous approaches to improve server operating systems to resist resource exhaustion. Some have considered better network protocol design principles to protect servers from attacks on stateful handshake protocols (familiar to those of ordinary skill in the art). IP trace back is another well-known approach—it is a network-wide coordinated effort to follow the offending packets back to their originators. However, such an approach obviously requires network-wide cooperation and coordination.
Moreover, DDoS attack tools may tend to mutate and evolve over time. With wider deployment of egress filtering, for example, attackers will undoubtedly exploit doors that are most likely to be left open (e.g., TCP, DNS). Attack signatures may change or disappear to evade detection. Thus, it is likely that sophisticated future attacks will become almost indistinguishable from legitimate ones. A filtering-based approach to the problem alone is, therefore, not only inefficient but also insufficient. Many false positives will force researchers to go back to the drawing board for new heuristics.
One particular type of DDoS attack on a TCP server can be launched by continuously creating new TCP connections with the targeted server until its limited resources are exhausted and it therefore becomes unable to accept service requests from legitimate users. (As is familiar to those of ordinary skill in the art, TCP is the well-known Department of Defense standard Transmission Control Protocol—see, e.g., “Transmission Control Protocol,” prepared for Defense Advanced Research Projects Agency by Information Sciences Institute, J. Postel, editor, Request for Comments (RFC) 793, September, 1981, “www.faqs.org/rfcs/rfc793.html.” RFC 793 is hereby incorporated by reference as if fully set forth herein.) Specifically, such attacks are known as “SYN attacks” since they consist of no more than an immense flurry of initial SYN packets which are sent to initiate new TCP connections. (SYN packets are connection request packets, fully familiar to those of ordinary skill in the art. They are defined and described in, for example, the TCP standard, RFC 793, referenced above.)
More particularly, as is well known to those skilled in the art, every TCP connection starts with a SYN packet. TCP servers must respond to every valid SYN request with a SYN, ACK and must retransmit it if necessary. (ACK packets are acknowledgement packets, also defined and described in RFC 793 and fully familiar to those skilled in the art.) SYN packets penetrate transient firewalls without prior states in them. They also cause servers and firewalls to allocate resources in preparation for new connections. As a result, they are the first potential vehicle for launching denial of service attacks.
In fact, there are two different forms of SYN attacks—SYN state attacks and SYN bandwidth attacks. SYN state attacks attempt to overwhelm a TCP server by sending connection request SYN packets without completing the rest of the handshake, causing the “backlog queue” on the server to eventually overflow, and thereby causing a denial of service to legitimate requests. (As is well known to those of ordinary skill in the art, TCP connections are established via a three-way handshake, with incomplete connections typically being held in a per-listener queue. The limit of this backlog queue is usually rather small.) However, at least two solutions already exist which allow TCP servers to defend against SYN state attacks by themselves—one is to reduce the amount of memory used for incomplete connections, and the other is to eliminate any memory usage entirely.
The other form of SYN attack however is a SYN bandwidth attack. SYN bandwidth attacks are more difficult to deal with “downstream” (i.e., at the TCP server under attack). Note that a typical SYN packet is no more than 64 bytes long. A burst of such minimum size packets can therefore cause livelock on the server. (As is well known to those of ordinary skill in the art, “livelock” is a condition which occurs when two or more processes continuously change their state in response to changes in the other process or processes without doing any useful work.) That is, a deadly attack could consist of simply blasting the server's ingress link with many such small packets. Although many optimizations exist to avoid receiver livelocks, in general bandwidth attacks have heretofore only been dealt with further “upstream”—i.e., before the damage is done at the server.